Seems like a good idea, although the idea seems similar to an earlier PR. Maybe @infinisil knows the status of that?

I think you'll want isString, because isStringLike also accepts path values, which are added to the store when interpolated.
Supporting derivations also doesn't seem right for a type like this.

I think in many cases, users of the type will want not just path strings, but absolute path strings.
It seems that we're in the process of creating a messy api with many distinct type names for unclear use cases. Perhaps it'd be better to do something like this?

pathWith { store = false; absolute = true; }

I'd like a more compositional style (e.g. set-like operations on types), but I'm not sure that it's actually nicer for users. Probably the type description - ie docs - would suffer as well.

I think you'll want isString, because isStringLike also accepts path values, which are added to the store when interpolated.

Fair, changed.

I think in many cases, users of the type will want not just path strings, but absolute path strings.

Yeah, you'll see I am checking if the first character is a /. Agreed that this is messy/unclear.

Perhaps it'd be better to do something like this?

pathWith { store = false; absolute = true; }

I like that. Happy to implement that, but first I'll wait to hear back from @infinisil about the status of the earlier PR you referenced.